1. Field Of The Invention
The present invention includes but is not limited to methods and systems for providing security for corporate payments through a corporate bank (hereafter, Financial Service Provider or FSP) to a payee such as corporate partner (hereafter, Trading Partner or TP). The case of the Financial Service Provider (FSP) is included in order to illustrate and clarify this disclosure. The present inventions also relate to methods and systems for incorporating indicia of authority within digital certificates.
2. Description Of The Prior Art And Related Information
Every corporation may be presumed to have a Chief Executive Office (CEO), Chief Financial Officer (CEO) or a person or persons that operate in that capacity. Such a person typically designates employees with authority to approve payments and/or authorize the FSP to make payments to the TP for goods and/or services provided by the TP to the corporation. To prevent fraud or mistake, such payments should be approved before the corporation's account with the FSP is debited. Preferably, the person or mechanism established to approve such pending payments should be authenticated (their identity verified to insure that the person or mechanism is who or what he, she or it purports to be) prior to the payment to the TP being released. Authentication is required for an FSP to perform financial service related transactions. There are several means of securing authentication, including passwords, smart cards, certificates, and even biometrics measurements such as retinal scans or voice recognition. Of these, the use of certificates and digital signatures, smart cards, and biometrics are referred to as “strong” levels of security, while the ordinary password-protected access is deemed “weak” by typical financial institutions and security experts.
Applications that generate payment requests to an FSP conventionally do not assume any responsibilities for strong authentication, being only the means by which a representative of a corporation generates non-XML files to send to and from FSPs and sellers. Conventional systems work, but do not meet the higher standards that banks set for electronic business banking. Strong authentication beyond the typical id and password pair is needed.
All current payment options, whether credit card or EFT, put the responsibility on the corporation to assure its own security and proper use of the payment system. Only the supposed source of a message from the corporation vouches for the authenticity of the payment request. As can be appreciated from the above, there is a need to prevent fraud and to control access to and use of payment requests generating computer application.
The primary corporate payment instruments are: paper checks, Electronic Funds Transfer (EFT), EXtensible Markup Language (XML) messages, credit cards, and purchase cards. Each payment instrument has its existing set of security models, yet none of them are totally satisfactory. All existing security models focus on given payment instruments, largely to the exclusion of the others. Alternatively, security risks vary widely among these methods of payment. Paper checks have the longest tradition as a payment method, which usually consists of the matching of a signature on the check against a signature on a signature card. Some checks of high value may require two signatures to be valid. However, for efficiency reasons, signatures are not commonly examined by the FSP as they are processed, except perhaps to insure that the correct number of signatures is present. If the account has sufficient funds, the check will usually clear regardless of signature. The corporation, then, must discover any discrepancies during a reconciliation process, applying to the FSP to reverse check and charges as appropriate. This results in contention between the FSP and the corporation, as the FSP tries to shift assumption of the risk of bad checks to the corporation, while the corporation typically believes the FSP should assume this responsibility. This is an ongoing problem for many corporations and their FSPs.
In a typical scenario, the FSP receives checks for clearing against the corporation's account until 2 pm (for example) each day. In addition, the FSP accumulates pending payment requests from servers used by the corporation. Such requests may not have digital signatures. If they do not, the FSP typically has no non-repudiable means of determining the legitimacy of the payment request. The paper checks received for clearing against the corporation's account may or may not be legitimate. FSPs typically no longer inspect signatures and compare them against signature cards unless they have received a specific request to do so. At the end of the business day (such as at 5 pm, for example), the FSP debits the corporation's account for the amounts in the received payment requests and correspondingly credits the accounts of the purported payees. The FSP will then typically print a statement at the end of the month and send it securely to an authorized person at the corporation for reconciliation against the corporation's accounting system.
EFTs are customarily handled by agreement between corporations and their FSPs, with some electronic banking systems permitting EFTs. Some EFTs and corporations rely on security based upon a combination of an ID and a password, with or without private networking (such as a Virtual Private Network or VPN) and Public Key Infrastructure (PKI) certificates. EFT security typically requires a signature on paper to back up whatever other security means have been selected. Moreover, the measures aimed at securing EFTs are usually applicable only to EFT payments.
XML payments are under development by a variety of providers of services and technology. Typically, an XML payment system will include authorization through PKI certificate by a person identified through the certificate. The ancillary procedures, that is, the means by which certificates are generated and distributed, varies widely—in some cases, third party vendors participate in the security arrangements. Most such XML efforts have FSP sponsorship and may be presumed to have very high standards of security. None of the known systems for XML security either integrate with corporate Enterprise Resource Planning (ERP) systems or internal FSP procedures.
Credit cards are discrete instruments designated by an account number and an expiration date, both of which are known to the holder of the card. Unfortunately, these are easily learned by others and credit cards have historically not been regarded has having strong security. Federal law requires FSPs to assume responsibility for unauthorized charges over $50. However, FSPs would like to find others (usually the vendor who accepted the card—the payee) to take responsibility for the unauthorized charge. The usual control is that purchases made with credit cards are subject to predetermined limits. The only security measure usually associated with credit cards is that the merchant will verify by signature/picture on the physical card before submitting the purchase request to the card issuer. However, merchants rarely, in practice, compare the signature on the receipt with that appearing on the card. Moreover, such thin security measures are not typically available for purchases made over the telephone or Internet. Credit card fraud is a major problem in the U.S. and an even greater problem elsewhere. Such fraud affects both business and personal payments.
Purchase Cards (Pcards) are corporate credit cards that have high limits relative to credit cards. Pcards may be physically implemented as plastic cards, but their main function lies in supporting payments for corporate purchases over the facsimile, telephone or the Internet. The security provisions for Pcards vary widely, with ID/password being the highest level and none at all (use of the card number on a paper form) being the lowest.
Corporate use of credit cards and Pcards usually costs the corporation and the TP some fee paid to the FSP. Unlike consumer credit cards, the main risk involves fraud or improper use by unauthorized individuals rather than non-payment by the holder of the card. Even so, corporate losses could be considerable, as could those of the FSP. The TP is in a quandary, since there is no basis other than the means of communication for believing that a card number is valid and is being properly used. Faxed orders with the credit card number on the fax would be an example of security for the TP.
When requests for payment are received by a financial institution from a certificate holder, the sender of the message incorporating the request for payment may be authenticated by means of the certificate presented. However, for lack of alternative, the recipient of the message incorporating the request for payment and the certificate makes the assumption that the person so authenticated has also been authorized to represent and bind the company, which company is assumed to be the person's employer. Changes in the status of employment of that person (such as, for example, suspension, demotion, termination or promotion) or of the privileges granted to the certificate holder (such as signature authority) most often will materially affect the certificate holder's authority to bind his or her employer. Changes to the person's status of employment and/or authority often lag behind the continued use of the certificate. In other words, the person may have been recently terminated or suspended and that change in status may not be reflected in his or her certificate for an indeterminate period of time, thereby exposing the corporation to liability for transactions initiated or otherwise carried out by the employee through the issuance of one or more messages to the corporation's FSP. When an individual's authority is stored in a directory, changes to an individual's data within such a directory may not be preserved as a history of transactions, and the CA may have no information at all as to the authorization level of an individual employee. These issues make fraud on the company relatively easy to accomplish, such as when a recently terminated employee uses an otherwise valid certificate to issue payment requests to an FSP. The FSP may verify the validity of the certificate presented and carry out the payment instructions, with little or no recourse available to the company that has become bound by this fraudulent transaction.
An important goal of FSP in handling such transactions is, therefore, to insure that they are non-repudiable. The goal of non-repudiation is to prove that a particular transaction took place at the behest of a duly authorized representative of a company, so that liability for the transaction stays with the originator of the transaction (the company) and not the party who executed the transaction (the FSP). A non-repudiation feature establishes accountability of information about a particular event or action to its originating entity. This is an important security measure, as users are increasingly called upon to sign contracts for certain transactions or events; and FSPs want assurances that no FSP client will be able to repudiate such events, to thereby shift the liability for the transaction back to the FSP. To insure non-repudiation of transactions carried out by a financial application of the company, FSPs should require that those originating message-based transactions are unambiguously identified and authorized to do so. Server to server security is insufficient to meet this goal.
What are needed, therefore, are methods and systems for insuring strong security for all forms of corporate payments. From the foregoing, it is also clear that authentication alone is not sufficient to insure non-repudiation of actions taken by an FSP on behalf of its clients. What are needed, therefore, are methods and systems to insure that those who originate actions with an FSP are, in fact, authorized to originate such actions. What are also needed, therefore, are standards for strong authentication and quantifiable authorization operable in a distributed networked computing environment.